1. Field of the Invention
The present invention relates generally to computer software. More particularly, the present invention relates to network management software.
2. Description of the Relevant Art
The field of network management involves the management of networked devices, often remotely. A computer network is a linked group of two or more computers. Generally, networks may be classified as Local-Area Networks (LANs) or Wide-Area Networks (WANs). In a LAN, the computers or devices are typically connected together within a “local” area such as a home, office, or group of offices. In a WAN, the computers or devices are typically separated by a greater distance and are often connected via telephone/communication lines, radio waves, or other suitable means of connection.
Networks are usually classified using three properties: topology, protocol, and architecture. Topology specifies the geometric arrangement of the network. Common topologies are bus, ring, and star configurations. A network's protocol specifies a common set of rules and/or signals, such as Ethernet or Token Ring, that the networked devices use to communicate with each other. A network's architecture typically specifies one of the two major types of network architecture: peer-to-peer or client/server. In a peer-to-peer networking configuration, there is no server, and computers simply connect with each other in a workgroup to share files, printers, services, and Internet access. Client/server networks often include a domain controller to which all of the networked computers log on. This server may provide various services such as centrally routed Internet access, e-mail, file sharing, printer access, and security services.
Many types of devices may be managed over a network, such as printers, scanners, phone systems, copiers, and many other devices and appliances configured for network operation. Typically, such devices are managed via requests and events. A request is a message sent to a managed object. A request may be sent by a manager application to a managed object to query the object about a particular parameter associated with the object. A request may also be sent to a managed object to modify a parameter of the object. Alternately, an event is a message originating with a managed object. Events may be sent by managed objects to signal some change of state of the managed object, or to communicate information about the managed object. Managing such devices tends to require that the data types of each device's control parameters and signals be well defined. For example, a networked printer might have a Boolean status parameter which indicates whether the device is currently on or off and a control parameter which turns the printer on or off. A manager application may send a request to determine the on/off status of the printer. Then, once the status is determined, say, to be off, a subsequent request may be sent to modify the control parameter to turn the printer on. The printer may also be capable of generating an alert signal indicating, for example, that the toner level is low. In this case, an event communicating that fact may be sent by the managed object (the printer) to the appropriate manager application.
The network management software should be able to read and write these data correctly in order to manage the device. To do this, information about the data is required. Such information is referred to as metadata, or “data about data.” Metadata may typically describe what type of data (string, integer, Boolean, structure) an object has and how the data are formatted. Metadata is essential for understanding information related to managed devices, as well as information stored in data warehouses. Typically, network management software manages a given device by storing and manipulating a representation of its pertinent data as a software object, herein referred to as a “managed object.” This object is the virtual representation of the device on the network.
FIG. 1a illustrates an example of typical elements of a telecommunications network. The telecommunications world is characterized by devices such as cell phones, cell phone towers and other kinds of towers 156, phone systems 151, faxes 152, routers 153, switches 154, satellite dishes 155, etc., which may be interconnected via networks 108a. In response to the network management needs of this technology sector, a conceptual framework for telecom network management called Telecommunications Management Network (TMN) was developed by the Telecom Management Forum (TMF). TMN defines the relationship between basic network building blocks, such as network elements, different network protocols, and operations systems, in terms of standard interfaces. Generally, a TMN system includes Agent hardware 150, Manager software 170, and Agent software 160. The Agent hardware 150 includes the managed devices such as those shown in FIG. 1a. The Manager software 170 includes any application used to manage a networked device. These manager applications, or client applications, may be installed and executed on one or more client computer systems 171a, 171b, . . . , 171n. The Agent software 160 includes the software interface between the Manager software 170 (for communications via network 108b) and the Agent hardware 150 (for communications via network 108a). The Agent software 160 may be installed and executed on one or more server computer systems 161a, 161b, . . . , 161n. In some instances, the Agent software 160 and Manager software 170 may be installed and executed on the same computer system. The Agent software 160 may also reside, in whole or part, on the Agent hardware 150 itself.
A middleware standard used extensively in network management is the Common Object Request Broker Architecture (CORBA), which is provided by the Object Management Group (OMG). CORBA specifies a system that provides interoperability between objects in a heterogeneous, distributed environment and in a way transparent to the programmer. Its design is based on the OMG Object Model, which defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way. In this model, clients request services from objects (which will also be called servers) through a well-defined interface. This interface is specified in the OMG Interface Definition Language (IDL).
In CORBA, a client accesses an object by issuing a request to the object. The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters, if any. The object reference is an object name that reliably defines an object.
A central component of CORBA is the Object Request Broker (ORB). The ORB encompasses the communication infrastructure necessary to identify and locate objects, handle connection management, and deliver data. In general, the ORB is not required to be a single component; it is simply defined by its interfaces. The basic functionality provided by the ORB includes passing the requests from clients to the object implementations on which they are invoked. The ORB acts as the middleware between clients and servers. In the CORBA model, a client can request a service without knowing anything about what servers are attached to the network. The various ORBs receive the requests, forward them to the appropriate servers, and then hand the results back to the client.
In CORBA, a client first looks up the object (server) it wants to communicate with. The ORB, as a result of the lookup operation, returns an object reference (a handle) of the server to the client. The client then uses the object reference to invoke operations on the object as a function call in the chosen programming language. The ORB intercepts the client request, collects the information about the operation and the request parameter values, encodes it in IIOP, and sends it to the object (server). The ORB on the object side (server) translates the request into a programming language specific function call on the server object. The server object then processes the request and returns a response, if any. The ORB intercepts the response, encodes the response and its parameters into IIOP, and sends it to the client. The ORB on the client side then returns the response to the client as the return value of the function call originally made as part of issuing the request.
One example of a network management system which makes use of the CORBA ORB is Solstice Enterprise Manager™ (SEM) from Sun Microsystems, Inc. SEM relies on an application programming interface (API) named Portable Management Interface (PMI) for development of management applications. PMI may be used for communication between client manager applications and a Management Information Server (MIS). An MIS may provide direct communication with and/or manipulation of managed objects which represent managed devices on the network.
Management interfaces provide event-based (or callback-based) APIs to perform network management operations. PMI is such an event-based API. PMI uses a primary event/callback scheduler to dispatch events/callbacks to the client application. However, a client application could be designed to be multi-threaded, while PMI is single-threaded. A thread is an encapsulation of the flow of control in a program. Single-threaded programs execute only one path through their code “at a time,” or concurrently. Multi-threaded programs, on the other hand, may have several threads running through different code paths concurrently (i.e., substantially simultaneously, depending on the number of available processors). A context switch between two threads in a single process is considerably more efficient than a context switch between two processes. In addition, the fact that all data except for stack and registers are typically shared between threads makes them a natural vehicle for expressing tasks that can be broken down into subtasks that can be run cooperatively.
PMI has shortcomings if the client applications involved are multi-threaded. A multi-threaded client application may try to access or update the primary scheduler from different threads in an unsafe manner, potentially resulting in data inconsistencies, access collisions, coherency problems, and other errors. PMI cannot currently be used in a thread-safe manner in multi-threaded management applications, and therefore the scalability and performance of management applications that use PMI may be limited. As used herein, “thread-safe” refers to the property that a program may safely use or be used by multiple threads to avoid, for example, data inconsistencies, access collisions, coherency problems, and other errors.
One approach to making network management operations thread-safe would be to use a global lock to control access to PMI from different threads or processes. Under this approach, a single-threaded scheduler would maintain a queue of pending requests and responses. A “busy wait loop” would scan the PMI scheduler lock at a particular interval to determine whether anything is on the queue to be processed. Use of the busy wait loop might include acquiring the lock, letting a dispatch queue run for a particular number of loops to listen for requests or responses, and releasing the lock. However, it might often be the case that no requests or responses are found, and CPU cycles have therefore been wasted. Furthermore, since every thread would first need to gain access to the lock before accessing the primary scheduler, each such access would result in testing and acquiring the lock at regular intervals. Therefore, use of a busy wait loop would often lead to waste of critical CPU cycles when some threads were idle while others were busy. Such bottlenecks might be thread-safe but would limit the efficiency and performance of the system, including the client applications.
Therefore, improved systems and methods for accessing management interfaces are desired.